Part II - Chapter 6

1. Describe the risk planning processes goals. Why is each goal important? Define quantitative success criteria for each goal.

• a. Provide visibility for key events and conditions. 20%
  • By getting regular updates you can monitor and communicate the progress of the key events and conditions to the current risk scenarios.

• b. Reuse successful risk resolution strategies. 20%
  • By documenting risk resolutions you can refer back to them helping time and budget.

• c. Optimize selection criteria (e.g., risk leverage or risk diversification). 20%
  • By using the priority method and classification of the risk you can optimize your process by looking at what will take the most resources and decide the best course of action.

• d. Understand the next action for each high-severity risk. 20%
  • Once a high-severity risk is addressed it is important to flow right into the next part of the project. Mapping out the path of each risk is important to help with the flow of the project.

• e. Establish automatic triggering mechanisms. 20%
  • Setting the triggering mechanisms in the database is an important step in alerting the team of an item that needs attention.

• Each goal has an impact on the entire project. With these goals the focus is to capture key events and conditions, reuse successful results, optimize the criteria and look out to the future so you will be prepared.

2. Do you agree that risk scenarios should be developed for significant risks only? Justify your answer.

• I agree that risk scenarios should only be developed for significant risks only. The reason is if you do it for every risk you can end up generalizing risks because you have an overwhelming amount. By concentration on the significant ones you keep your focus on the important aspects of the project.

3. Describe the events and conditions in the following risk scenario: The development process has been ignored, and product defects are increasing.

• Possible events

• a. Error prone code will be created.
• b. Large amounts of code will have to be reworked as the project progresses and the design starts to come together.
• c. Testing is difficult to establish due to the changing design

• Conditions

• a. Each team member goes in a separate direction.
• b. There is no development focus.
• c. Errors are difficult to isolate because there is no documented program structure.

4. Discuss how you might use risk protection and risk transfer to combat a system reliability risk. Discuss the similarities and differences between these risk resolution strategies.

• One example I can think of for an example of risk protection and transfer is third party storage. If you are a medium size organization and don’t have the budget for a primary system with a mirror backup you can contract the service out. With contracting it out you remove the risk of maintaining and manning the additional hardware you would have purchased.

5. Many individuals within your organization have trouble keeping up with new technology. The learning curve for integrating new technology into your organization has been identified as a risk. Develop a risk resolution strategy to address this risk. Include your organization’s objectives, constraints, and alternatives.

• To assist with the learning curve, you have several options. The first thing you need to find out is how the organization learns the best. For example, do the users respond to class room instruction, step by step guides, videos, or hands on instruction. Once this is determined you can have a large training session using the best method that was found. You can also use the step by stem guides as a secondary option so you will have a product to leave behind.

6. A significant integration risk has been identified. The cause is determined to be a lack of through software testing due to insufficient time allocated to the integration and test phase. You have been assigned to investigate this risk and make recommendations to reduce the risk. Project management wants to maximize software quality and minimize total cost. How would you trade off these confliction objectives? What are your recommendations to project management regarding this risk?

• There are a number of potential solutions. First, determine the actual time line. Once that has been identified look at the testing process and estimate what the total testing time will be. Determine where the short fall is. To maximize software quality the emphasis needs to be on the testing aspect. Managing the testing schedule can be a simple matter of organizing the process. There is also a potential of brining in system users to “preview” the software allowing the team to focus on the integration while the actual system users test the software. This has several advantages; it allows the users to get an early look, become acquainted with the new product, and train other users when the software is released.

• Once you get a handle on testing you can concentrate on integration. Giving the team additional time to the integration process by allowing the users to perform the testing you save you a lot of time in the process. You are in effect killing two birds with one stone.

• After you have made a schedule and assigned tasks you can go to management with the plan. The customer should be able to supply the personnel for the testing. That should help you save on the budget by not having to bring a independent company for the process.

7. Discuss the risk leverage that exists in the operations and maintenance phase of the life cycle.

• The risk leverage that exists in the operations and maintenance phase of the life cycle is a huge budget concern. It is well known that a risk identified in the development stage is corrected at a much smaller cost then when it is identified at a later stage in the development process. When risk s are identified in the operations and maintenance phase they can be a huge drain on the budget. The costs to eliminate or reduce the impact can easily be a high dollar solution. You have to evaluate the cost of the risk before repair and what the estimate of what it will be after the repair. Then you divide it by the risk resolution cost. If the number is in the negative it will not be cost effective to fix the problem.

8. How can a threshold be used as part of an early warning system?

-

• The risk action plan need not be implemented immediately. Early in the project, risk assessments tend to identify important risks that are not yet urgent. Because their time frame is not immediate, these important issues tend to be overlooked in planning and forgotten in tracking. Unless you put a triggering mechanism in place, you might not remember to address the issue until it is too late. For early warning, you can use triggering devices based on quantitative targets and thresholds.

• Quantitative targets are the goals expressed quantitatively. They provide best in class objectives that can be determined by bench marks and metrics. Every measurement should have a full performance value defines the warning level, or threshold. Understanding the range of acceptable values provides meaning to measurement data.

• A threshold is a warning level associated with quantitative target. Thresholds establish the minimum acceptable values with respect to the quantitative target. Values over threshold define the inception of risk occurrence. Predefined thresholds act as an early warning system to indicate the need for action.

9. As a system engineer, you are responsible for requirements management. Develop a graph of expected software requirements volatility over the project life cycle. Define the quantitative target and associated warning level for software requirements volatility at each stage of development.

10. Discuss the following human traits that are useful in coping with uncertainty: attitude, belief, confidence, courage, faith, and imagination. Which trait do you think is the most important? Explain your answer.

• Here is my opinion on the following human traits:

• a. Attitude – Is very important. You either have a positive or negative one. By far the positive is most helpful because it keeps you focused on the ultimate goal of solving the problem. It also keeps the team’s energy up and everybody active. A negative one tends to bring the entire team down and makes thins very depressing.

• b. Belief – It is the team leader’s job to keep everyone’s mind on the ultimate goal of the project. If the team leader projects his belief in the project everyone can turn to him/her when they get discouraged and the leader can re-influence the team with the goal of the project.

• c. Confidence – A high confidence level is also important. If you project a lot of confidence in the project the team will see that what they are doing has a reason. If you can put the ultimate goal in a paragraph and use it as a mission statement it can give each member a stake in the project and thus increase the confidence level by letting everyone know what they are shooting for.

• d. Courage – It is important to be able to stand up for the team’s opinion of how things are and not always refer to management’s vision. There are times when management expects much more than what the resources can deliver. As a team leader it is your job to get each group to agree to a compromise. It takes courage to stand up for the group and keep them in a positive mind frame.

• e. Faith – As a leader you must instill trust in your team. When they have trust they will have faith in you that you will have their best interest in mind. By having the team put their faith in you to address their concerns and ideas you can more easily negotiate between management and the team because you can make compromises when necessary.

• f. Imagination – One of the more important qualities in your team members. The solution to problems usually lies in the out of the box thinking that is driven by imagination. Imagination is the inspiration for creativity and cannot be overlooked. There has to be a limit to where you let it go however, but as long as you keep it under control it can be a very useful tool to have.

Project Home Next Section